home *** CD-ROM | disk | FTP | other *** search
/ CYBER.XPO.95 / CYBER.XPO.95 (Arsenal Computer).ISO / popreq / amiga1 / dnbrrtt3.lha / j / j.42 < prev    next >
Text File  |  1994-01-14  |  8KB  |  165 lines
  1. Subject: 1993 IPISA Conference Proceedings article
  2.  
  3.               10 AMIGA PROGRAMMING TIPS FOR THE REAL WORLD
  4.  
  5.                            Daniel J. Barrett
  6.                     Department of Computer Science
  7.                      University of Massachusetts
  8.                          Amherst, MA  01003
  9.                                  USA
  10.  
  11.                     E-mail: barrett@cs.umass.edu
  12.  
  13.     When Sergio Ruocco kindly asked me to contribute an article for these
  14. proceedings, I was very excited.  You see, I am an Amiga programmer too, and
  15. I have always dreamed of sharing my favorite programming tips at a
  16. conference full of experts!  The following article explains the ten most
  17. effective secrets for writing the ultimate Amiga program.
  18.  
  19.     For years, I've been reading millions of "programmer tips" articles
  20. in magazines, and personally, they make me sick.  No matter how clever the
  21. suggestions are, the authors always forget one very important point: if you
  22. are the programmer, then YOU ARE IN CHARGE.  Who CARES what the users think?
  23. If they don't like the way your program works, then let the ignorant fools
  24. write their own.
  25.  
  26.     With this in mind, I hereby present 10 programmer tips for the real
  27. world.  These are GUARANTEED to triple your productivity within 24 hours!
  28. Well, at least double it.  Or maybe cut it in half.  I forget.  But they will
  29. DEFINITELY help you; and if they don't, then you have my permission to throw
  30. these conference proceedings off a cliff and go join a religious cult.
  31.  
  32. (1) Don't plan your program in advance.
  33.  
  34.     Seriously, now... planning your program in advance is a total waste
  35. of time, and you know it.  Programming is an art form; and as sensitive
  36. artists, we must not be rushed into making decisions.  Will your program
  37. have a command-line or a graphic interface?  An ARexx port?  Will it be a
  38. database or a shoot-em-up game?  IT DOESN'T MATTER.  Just start coding, and
  39. worry about these insignificant details later.
  40.  
  41.     Even better, just start COMPILING... even before you have decided
  42. what your program is going to be.  Running the compiler or assembler a lot
  43. before you write any code will "warm up" your computer, and your software
  44. will have fewer bugs.  Trust me.  I ran my compiler 50 times last night
  45. without writing a single line of code, and so far my program has no bugs.
  46.  
  47. (2) Don't use the standard libraries.
  48.  
  49.     No real Amiga programmers use the stuff in LIBS:, or even Kickstart.
  50. It is FAR better to do all the work yourself and create an entire operating
  51. system from scratch.  This is REALLY impressive.  Your users will be stunned,
  52. and beautiful, sexy movie stars from around the world will travel thousands
  53. of miles to ask you out on dates.  Believe me, it's true.  I have a hot date
  54. with Cindy Crawford tonight because she loves my custom Exec list structures.
  55.  
  56. (3) Don't use "Make".
  57.  
  58.     Face it:  "Make" is for wimps.  REAL programmers KNOW which files
  59. are compiled and which ones aren't.
  60.  
  61. (4) Keep your user interface inconsistent.
  62.  
  63.     Who needs standards?  It is much better if every programmer invents
  64. his/her/its own user interface style, for three reasons.  First, it lets
  65. programmers be creative and helps to relieve stress.  Second, by making your
  66. program harder to use, it gives users valuable practice in working with
  67. difficult software.  Finally, we know that users are incredibly lazy
  68. creatures, and a little suspense keeps them in shape.  It's for their own
  69. good.
  70.  
  71.     So, don't be afraid to take some chances and make your interface
  72. really unique!  Instead of the right mouse button, use double-clicks to bring
  73. up menus.  Make your window resize gadgets act like close gadgets, and
  74. vice-versa.  Fix your text color and background color to be the same.  Be
  75. inventive, and your users will thank you for it.
  76.  
  77. (5) Hard-code your fonts.
  78.  
  79.     Why waste time making your program font-sensitive?  Hey, if "Topaz 8"
  80. is good enough for Commodore, it's good enough for everyone.  Or to make your
  81. programs look truly unique, I recommend using a really obscure third-party
  82. font (e.g., "WalrusBreath 91-point").  If the font isn't found in the user's
  83. FONTS: directory, then your program should put up a polite, friendly
  84. requestor and then crash.
  85.  
  86. (6) Hard-wire all your screens to 320x256 PAL (or 320x71 in NTSC).
  87.  
  88.     Some users will complain if programs don't take advantage of
  89. overscan, but they are just whiners.  YOU wrote the program, so YOU will
  90. know which screen sizes are best.  And while you are at it, you should also
  91. hard-code the palette and number of bitplanes.  That will teach those pesky
  92. users a lesson.
  93.  
  94. (7) Use heavy copy protection.
  95.  
  96.     Especially for freeware, where dongle protection is a must.
  97.  
  98. (8) Ignore playability.
  99.  
  100.     Hey, if the users can't play your game, they're wimps.  Let them
  101. go play checkers instead.
  102.  
  103. (9) Write all of your documentation at the last minute.
  104.  
  105.     If you want complete freedom in your programming, it simply is not
  106. practical to write your manuals early.  Wait until later:  say, after the
  107. program has been shipping for a few months.  By then, you will have a good
  108. idea of what the program can do, and you're reading to create the docs.
  109.  
  110.     If possible, avoid paper manuals entirely and document the whole
  111. program in a "README" file on the program disk.  I know that some users don't
  112. like README files because the information often isn't presented in a natural
  113. order.  So, if you feel obligated to please your users, I recommend running
  114. your README file through C:Sort.
  115.  
  116.     Another option is to use Commodore's AmigaGuide format.  This is an
  117. excellent idea, but many programs do not take full advantage of this
  118. hypermedium.  In most AmigaGuide documents I've seen, fewer than 10% of the
  119. words appear as buttons.  For maximum benefit, EVERY word should be a
  120. button... even the AmigaGuide window title bar.
  121.  
  122.     If you do decide to use on-line documentation, you might consider
  123. putting it on a BBS instead of on disk, so you can make changes to it easily.
  124. If you are feeling nice, you can even tell your users the BBS telephone
  125. number, but this is not required.  (To make things easier, put the phone
  126. number in the documentation file.)
  127.  
  128. (10) Don't use the Commodore Installer.
  129.  
  130.     When it was introduced, the Commodore Installer was a significant
  131. advance over manual installation.  Instead of forcing the user to make
  132. Assigns and execute obscure "Copy" commands, the Installer guides the user
  133. through a friendly set of easy-to-understand prompts, such as "Please insert
  134. directory 'READ/WRITE_ERROR' in any drive."
  135.  
  136.     Nowadays, however, the Installer has been replaced by more powerful
  137. utilities.  The best one available today is called BLAZE-INSTALL, created by
  138. those ultimate programmers at BLAZEMONGER INCORPORATED.  BLAZE-INSTALL is so
  139. easy to use that you don't even need a single mouse-click to install the
  140. software.  Heck, you don't even have to insert the installation disk!  Just
  141. unwrap the package, and BLAZE-INSTALL does the rest.  If a file is missing,
  142. BLAZE-INSTALL automatically generates it... even complete programs!  In
  143. fact, BLAZE-INSTALL is the last program you (or anybody) will ever need to
  144. buy, since it can create any other piece of software in existence.  So I
  145. guess we programmers should all just go home and find other jobs.
  146.  
  147.  
  148.     Well, those are my 10 most useful Amiga programming tips.  I hope
  149. that you found them useful, or at least mildly destructive.  If you'd like
  150. further information on Amiga programming, I strongly recommend the books
  151. "Amiga Tips, Tricks, and Terrorism" by Ira Sadist, and "Kicking the Hell out
  152. of Kickstart" by Pal Booter.  Have fun!
  153.  
  154. ==============================================================================
  155.  
  156. Daniel J. Barrett, a doctoral student in computer science at The University
  157. of Massachusetts, is an Amiga humorist on USENET and the inventor of
  158. BLAZEMONGER.
  159.  
  160. ---
  161. Copyright 1993 by Daniel J. Barrett.  All rights reserved.
  162. This article may be freely distributed as long as it is distributed in its
  163. entirety.  It may not be included in any publication without the written
  164. permission of the author.  So nyaaah.
  165.